Remarks 



Reconsideration of the application is requested in view of the amendment above 
and comments which follow: 

1. Claim rejections 35 USC S 112 

Claim 17 has been amended to replace the wording "the replication service 
memory space" with "the contact manager memory space", rendering this 
rejection moot. 

2. Claim rejections 35 USC § 102 

2.1 Rejection of claims 1-7 as being anticipated by Hemm et al. 
2.1.1 Claim 1: 

In relation to claim 1, Hemm fails to disclose or fairly suggest several claim 
limitations, and for each such limitation which is not disclosed or suggested, 
Applicants respectfully submit that the allegation of anticipation is erroneous. 

A. "creating a new software object for said received contact; " 

The Office Action says that Hemm teaches the creation of a software object at 
e.g. [0029], lines 14-16 because (in the words of the Office Action): "a vector is 
created in assigning priority and servicing each contact". 

This is, with respect, erroneous in two respects. Firstly, the "vector" discussed by 
Hemm is not created when the contact is received. Secondly, the vector is not a 
software object at all, but is rather a program used to assign conventional 
contacts (which are not software objects) to conventional queues. 

The passage in question says that "Included among the control programs in 
the server 110 is a contact vector 216 [emphasis added]. Contacts incoming to 
the contact center are assigned by contact vector 216 to different contact queues 
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208a-n based on a number of predetermined criteria, including customer identity, 
customer needs, ..."etc. 

Firstly, therefore, contact vector 216 is a control program which is part of the 
software existing on the server at the point in time when incoming contacts are 
received. It is thus not "created ... for said received object". 

Secondly, and more fundamentally, the contact vector, which is explicitly said to 
be a program to assign incoming contacts to different queues, cannot be a 
software object created for the received contact. 

For these reasons, the limitation of "creating a new software object for said 
received contact" is not taught or suggested by Hemm, and claim 1 is novel. 
Further and independent reasons for considering claim 1 novel also follow. 

B. "adding to said new software object a reference to said at least one other 
software object" 

The above limitation is alleged to be disclosed, based also on [0029], "because 
the contact vector associated with each contact has predetermined criteria in 
relation to other contacts to provide for the matching of agent with each contact 
based on the prioritized agent skill level". 

This is without any foundation in Hemm. There is no "contact vector associated 
with each contact" - the vector is the program that places a contact in the queue. 

There is also no teaching whatsoever of one software object referring to another 
software object. Applicants fail to see how the description of the contact vector 
program in paragraph [0029] could give rise to any such understanding. 

Therefore, the limitation of "adding to said new software object a reference to said 
at least one other software object" is not taught or fairly disclosed and this 
provides a further, independent reason why claim 1 should be recognized as 
being novel over Hemm. 
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C. "storing in memory a collection of said software objects each containing a 
reference to at least one other of said software objects; whereby said stored 
collection of said software objects provides a prioritised queue for a skillset" 

The above limitation is similarly alleged to be disclosed, based also on [0029], 
"because the contact vector associated with each contact has predetermined 
criteria in relation to other contacts to provide for the matching of agent with each 
contact based on the prioritized agent skill level". 

Again, Hemm says nothing to suggest the storage in memory of a collection of 
software objects, each containing a reference to at least one other of said 
software objects, whereby said stored collection of said software objects provides 
a prioritized queue for a skillset. 

The passage in paragraph [0029] does not teach contact vectors associated with 
each contact: the contact vector is a program for directing contacts into 
conventional queues, and is not a software object. 

There is no suggestion anywhere within Hemm that the entirely conventional 
queue could be replaced by a collection of inter-referenced software objects. 

Accordingly, these provide yet further, fundamental and independent reasons why 
claim 1 is not anticipated by Hemm et al. 

In summary, in relation to claim 1 , three distinct limitations are missing from 
Hemm, all relating to the creation and properties of software objects associated 
with individual contacts. The argument in the Office Action appears to be based 
on the understanding that the "contact vector 216" is a "software object associated 
with said received contact", but of course a "software object" is different from a 
program and the skilled person would not equate a software object having 
references or pointers with a computer program for prioritising contacts. 
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2.1.2 Claims 2-7: 

Each of claims 2-7 is dependent on claim 1 and therefore not anticipated by 
Hemm for at least the reasons given above. 

2.2 Rejection of claims 12 as being anticipated by Mears et al. 

Claim 12 was previously rejected as being anticipated by Mears et al., and in 
Applicants' response of August 7, 2007, arguments against this rejection were 
presented, with reference to the arguments made regarding claim 8. 

The most recent Office Action states that Applicants' arguments are moot in view 
of the new grounds of rejection, but claim 12 is being rejected on the same ground 
as before, namely anticipation by Mears et al. 

Accordingly the arguments previously presented in relation to claims 8 and 12 are 
incorporated herein by reference, and it is pointed out for brevity that the "new" 
ground of rejection does not provide any indication of why Mears might be 
considered to disclose a network of contact centers. 

It is pointed out further that notwithstanding the repeated use of the phrase "the 
assignment manager within each contact center" in the rejection, there is only one 
contact center under discussion in Mears. 

This in turn means that the requirements of claim 12 that the program steps of 
requesting from a plurality of networked contact centers the highest priority 
queued software object in each contact center and receiving information from a 
number of contact centers cannot be found in Mears et al. Once again, these 
arguments are developed in depth in Applicants' last response and are thus not 
moot as alleged, and should be considered if the rejection over Mears is to be 
maintained further. 

3. Claim rejections 35 USC S 103 

3.1 Rejection of claims 8 and 9 over Zellers et al. in view of Hemm et al. 
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3.1 .1 The Office action says that Zellers teaches: 

- each contact being represented by a software object maintained at a 
contact center 

- references to one or more software objects maintained at the same contact 
center 

Applicants point out respectfully that Zellers has no such teaching. Zellers does 
not have any disclosure of a contact center, or of the management or 
representation of contacts in contact centers. Nor is it suggested that Zellers has 
any applicability to contact center management and to the representation of 
contacts. 

Since the above features of claims 8 and 9 are not present in Zellers as alleged, 
the suggested combination fails to teach each and every limitation of the claimed 
invention, and patentability should be recognized. 

If the Examiner intends to maintain the rejection, Applicants respectfully request 
that the basis within Zellers for finding that there is a disclosure of a contact center 
and of the representation of contacts within a contact center might be expressly 
identified, to assist in responding to the rejection. 

3.1.2 Notwithstanding the arguments made above, the rejection over Zellers in 
view of Hemm is further deficient in that Hemm fails to provide any teaching of 
representing a contact by a software object, for the reasons given above in 
relation to claim 1 . 

For this reason also, claims 8 and 9 would not have been obvious over the 
suggested combination. 

3.1.3 The rejection is further deficient in that Hemm does not teach or suggest 
requesting from each contact center the highest priority queued object matching 
said criteria. The passage relied on in this regard, paragraph [0016], lines 14-16 
says that an agent may call back a transitory high value contact. 
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Applicants fail entirely to understand how this sentence is in any way to be 
understood as implying that a plurality of contact centers are each requested to 
provide their highest priority software object matching certain criteria. It is pointed 
out that no mention is made of requesting software objects from a plurality of 
contact centers, and if this rejection is to be maintained, the Examiner is 
respectfully requested to clarify how this limitation is understood as being implied 
by the passage in question. 

For this reason also, therefore, claims 8 and 9 would not have been obvious over 
the suggested combination. 

3.1 .4 Regarding the allegedly implicit disclosure of receiving information relating 
to each such highest priority queued object from a plurality of contact centers, 
again on the basis of paragraph [0016] of Hemm, the comments in paragraph 
3.1.3 above are relied on. Hemm makes no mention of receiving information 
relating to the highest priority queued object from each of a plurality of contact 
centers, and Applicants are unable to understand how the passage in Hemm can 
be understood as implying any such feature, given the lack of any mention of 
software objects representing contacts at a plurality of contact centers. 

For this further and independent reason, therefore, claims 8 and 9 would not have 
been obvious over the suggested combination. 

3.1.5 The feature of determining which software object represents the contact 
with the highest priority and/or best match is not disclosed, as alleged, in 
paragraph [0003] of Hemm, since Hemm does not disclose any software objects 
representing contacts whatsoever, as explained previously. 

For this further and independent reason, therefore, claims 8 and 9 would not have 
been obvious over the suggested combination. 

3.1 .7 Regarding the features of claim 9, the fact that contacts in a conventional 
queue reach the head of a queue does not, as alleged, imply the updating of 
objects which contain references to the selected object, again for the reason that 



13 



Hemm's contacts are not represented by software objects containing pointers to 
one another and Hemm's queues are not represented by collections of such 
objects. 

Accordingly, this provides a further reason why claim 9 would not have been 
obvious over the suggested combination. 

3.1.8 The alleged motivation to combine Zellers with Hemm is based entirely on 
hindsight and is not supported by the content of either document. Zellers is 
entirely remote from the field of contact center management, and the skilled 
person would have no reason whatsoever to make a wholesale and far reaching 
modification of Zellers with the teachings of Hemm. 

This point is made without prejudice to the seven earlier reasons why the alleged 
combination would nevertheless be deficient given the failure of both Zellers and 
Hemm to disclose almost every significant limitation of claims 8 and 9. 

3.2 Rejection of claim 10 over Hemm et al. in view of Pauly et al. 

3.2.1 As previously pointed out, Hemm does not in fact disclose numerous 
features of claim 1 also present in claim 10, including all of the features requiring 
contacts to be represented by software objects and the queue to be provided as a 
collection of such objects having references to other objects. 

Accordingly, Hemm is at least equally deficient in relation to claim 10 as it is in 
relation to claim 1, and claim 10 would not have been obvious over the suggested 
combination. 

3.2.2 Furthermore, there is no disclosure of determining from the network the 
highest priority queued software object as alleged in relation to paragraph [0011] 
of Hemm, since there is no disclosure of software objects representing contacts at 
all. 
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3.2.3 Turning next to Pauly, it is noted that the feature which is acknowledged 
to be missing from Hemm, namely "maintaining a network queue of contacts by 
automatically replicating changes in contact software objects at each contact 
center with corresponding changes in contact software objects in said network 
queue", is not alleged to be disclosed in its entirety in Pauly, suggesting that the 
rejection is prima facie incomplete. 

Instead, this claim wording is varied in the Office Action to omit the important 
requirement of replicating changes in "contact" software objects "at each contact 
center". 

Pauly clearly does not disclose changes in contact software objects at each of a 
number of contact centers, and the Office Action does not suggest that Pauly has 
any such disclosure. Pauly is concerned with replication of changes in various 
databases which are not contact centers. There is no teaching of a network 
queue of contacts. 

Accordingly, no prima facie case is made out for claim 10, would not have been 
obvious over the suggested combination. 

3.2.4 It is further submitted that notwithstanding the above points, there is no 
motivation in any of the prior art to make the suggested combination. The alleged 
motivation is to "successfully control a database of customer attributes including 
contact information". That is not what claim 10 is concerned with at ail - the point 
is to provide a network queue of contacts which mirrors changes in contact center 
queues in a network queue, and neither Pauly nor Hemm is in any way concerned 
with network queues. 

3.3 Rejection of claim 11 over Hemm et al. in view of Florman et al. 

The arguments made above in relation to Hemm apply equally to claim 11, and 
thus claim 1 1 is patentable for the same reasons at least as claim 1 . 

The Office Action alleges that Florman teaches "a method including limitations of 
creating a software object for each contact (see claim 6, lines 2-5, which teaches 
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this information because the software objects are implemented to provide contact 
and help center information)." 

Applicants respectfully point out that claim 6, lines 2-5 appear to be entirely 
unrelated to any such disclosure. Applicants have diligently tried to establish what 
passage the Examiner might have intended to refer to (e.g. looking at col. 6, lines 
2-5, rather than claim 6), but fail to understand what argument is being made in 
view of the evident error in the Office Action. In the event that the rejection is to 
be maintained, and bearing in mind the fundamental deficiencies of the Hemm 
reference, it is requested that the rejection be clarified so that the relevance of 
Florman can be understood, or if a different reference is intended, identification of 
that reference. 

In view of the incomplete argument in the rejection, Applicants are unable to 
comment further and in particular do not concede the propriety of the suggested 
combination. 

3.4 Rejection of claim 13 over Mears et al. in view of Florman et al. 

Without repeating the points in detail, Applicants rely on the points made 
regarding claim 12 and the shortcomings of Mears as a reference. 

Applicants further point out that the problems regarding the Florman reference, 
pointed out in section 3.3 above, apply equally to this rejection. 

3.5 Rejection of claim 14 over Mears et al. in view of Hemm et al. 

The arguments referred to above in relation to claim 12 apply equally to claim 14, 
and Mears thus fails to teach several of the features referred to, for the reasons 
given in both this response and Applicants' earlier response when addressing 
claim 8. 

3.6 Rejection of claim 15 over Zellers et al. in view of Hemm et al. 
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3.6.1 Zellers does not teach, as alleged, "a software object representing a 
contact at a contact center". The passage relied on in making this rejection, 
namely paragraph [0020], lines 13-15, which read as follows: 

The server software object and the client software object allow an 
application program to communicate using the at least two communication 
protocols without direct knowledge of the at least two communication 
protocols. 

Given this clear failure to disclose a software object representing a contact at a 
contact center, as alleged, the suggested combination fails to disclose all of the 
claimed limitations. The reasoning that "a client creates a client software object 
for communication purposes" is noted but Applicants respectfully do not 
understand what relevance this might have to the question of whether or not the 
software objects represent contacts at a contact center. Further clarification is 
respectfully requested if it is intended to maintain this rejection. 

3.6.2 The feature of "said software object including a reference to one or more 
other such software objects immediately ahead of or behind said software object 
in a queue" is not disclosed by Zeller, and the relevance of paragraph [0076, lines 
2-4 is not understood. This passage states that messages are added to a queue 
of requests awaiting processing by the next available worker thread. No mention 
is made of any references between neighbouring software objects in a queue of 
such objects. Again, further clarification is respectfully requested if it is intended 
to maintain this rejection. 

3.6.3 Hemm does not teach or suggest the feature of a "software object 
including an identifier to the contact which it represents and a skillset identifier 
enabling the software object to be identified in a search for software objects 
representing contacts which match given skillset criteria." 

The passage relied on at paragraph [0003], lines 3-6 makes no mention 
whatsoever of using software objects at all, let alone using them to represent 
contacts, or of providing identifiers between such software objects and such 
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contacts allowing searching of software objects to find contacts matching given 
criteria. 

3.6.4 Given the lack of any mention of contact centers in Zellers and the lack of 
any mention of software objects in Hemm, the alleged motivation to combine the 
two references is not present. 

3.6.5 For each of the four reasons cited above, the suggested combination fails 
to teach the subject matter of claim 15. 

3.7 Rejection of claim 16 over Zellers et al. in view of Mears et al. 

3.7.1 The rejection of claim 16 is based in part on a finding that the software 
objects as recited in claim 15 are disclosed in part by Zellers, and the arguments 
made in sections 3.6.1 and 3.6.2 apply equally in rebutting the claim 16 rejection. 

3.7.2 The remainder of the rejection appears to refer to both Hemm and Mears, 
and the reasoning cannot be followed with any certainty. However, it would 
appear that the references should all be to Mears, and the allegation that there is 
a disclosure of software objects with identifiers of contacts, based on col. 1, lines 
20-28, is erroneous. Mears does not make any such suggestion. 

3.7.3 For these reasons at least, the combination of Zellers and Mears does not 
render claim 16 obvious. 

3.8 Rejection of claim 17 over Hemm et al. in view of Wood et al. 

3.8.1 Claim 17 is dependent on claim 6 and thus indirectly on claim 1. It thus 
benefits from the patentability of claim 1 for at least the reasons discussed above. 

3.8.2 Wood makes no disclosure that a contact manager memory space and a 
queuing module memory space are each provided. Wood makes no suggestion 
that a replication service is provided. The entire argument based on Wood seems 
to be based on inherency, but without there being any teaching of how the 
specifically claimed features of claim 17 would be arrived at. 
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3.8.3 For each of these reasons, the suggested combination fails to teach or 
suggest each of the claimed limitations of claim 17. 

In view of the amendments and arguments made herein, Applicants respectfully 
request the examiner withdraw the rejections, and allow the application. 

An appropriate Petition for Extension of Time is also submitted herewith. 



April 3, 2008 Respectfully suj^mittecjC 




William M. Lee, Jr. 
Registration No. 26935 
Barnes & Thornburg LLP 
P.O. Box 2786 
Chicago, Illinois 60690-2786 
(312) 214-4800 
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